第 1 章 / Planning Session

StoryCam Autoplan 与实施计划定稿

这一章记录 StoryCam 从“产品愿景 + Stitch 设计稿”进入系统化实施计划的过程：用 gstack-autoplan 连续审查产品、设计、工程和开发体验，并把最终计划收敛成中文 canonical docs。

本章阅读路线图

从设计稿进入计划审查

用户指定 Stitch 设计和 docs 作为输入，启动 gstack-autoplan。

产品方向被收窄

从完整六工作台改为一个私人记忆预告片 spike。

真实视频改变工程结构

引入异步 job、幂等、取消、删除和 provider 边界。

计划文档中文化

将实施计划和测试计划收敛为中文单份文档。

确定下一步

继续开发时先做 Phase 0；提交计划时再走 /gstack-ship。

TL;DR

本 session 的核心任务是把 StoryCam 的产品和设计输入转成可执行的工程计划，而不是直接写功能。
用户明确要求使用 gstack-autoplan，并提供 AGENTS 约束：StoryCam 是 Web-first 的私人故事剧场，不是工业短剧后台。
CEO review 将第一版从“完整工作站”收窄到 Private Memory Trailer Spike：一个模板、一个核心时刻、一个真实 Seedance clip。
Design review 把 Stitch 设计降级为结构参考：保留流程骨架，放弃 cyber workstation 语气。
Engineering review 明确真实视频必须走异步 GenerationJob，并提前处理幂等、重试、取消、删除和 late result。
DX review 把 Phase 0 提前：先补本地运行、mock mode、provider contract、隐私日志和测试命令。
用户随后要求计划文档只保留中文一份，最终 canonical docs 收敛为中文实施计划和中文测试计划。
最后检查 gstack 技能包后，下一步被明确为：继续实现走 Phase 0；若只是提交计划变更，才走 /gstack-ship。

本章学习目标

学会用约束收窄 AI 产品

不是把设计稿中所有能力都做出来，而是从产品承诺反推第一条验证路径。

学会区分视觉参考和产品真相

Stitch 能提供结构和能量，但用户定位、语言和节奏要由产品文档决定。

学会提前识别真实 provider 的工程后果

一旦进入真实视频生成，就必须考虑成本、延迟、幂等、取消、删除和日志脱敏。

学会把计划转成开发者入口

Phase 0 不是“写文档拖延”，而是让后续实现可运行、可测试、可复现。

工具、参考图和可视化证据

关键参考图：StoryCam UI Flow Board

这张图来自项目内设计文档资源，用来说明本 session 的设计输入不是抽象讨论，而是已有一组围绕 StoryCam 流程的 UI flow reference。它在本章中的意义是：帮助读者理解为什么后续评审会讨论“Stitch 结构可以保留，但产品语气必须调整”。

图片路径：../docs/design-docs/assets/storycam-ui-flow-board.png

用到的技能和流程

gstack-autoplan
顺序运行 CEO、设计、工程、DX 四类计划审查。

gstack 评审日志
记录 plan-ceo-review、plan-design-review、plan-eng-review、plan-devex-review 的完成状态。

本地文件检查
用 rg、find、git status 确认文档、设计图和工作区状态。

关键参考材料

AGENTS.md：定义 StoryCam 的核心产品约束。
docs/README.md：项目 canonical docs 索引。
docs/product-vision.md：产品愿景与定位。
docs/design/storycam-ui-design.md：原始 UI 设计 brief。当前工作区路径后续有调整，本文不臆造其现状。
docs/design-docs/assets/storycam-ui-flow-board.png：可视化流程参考图。

沿时间排列的原始 Prompt

Prompt 1：启动 gstack-autoplan

“/Users/vc3vc3/Documents/code/storycam/docs/design/stitch_storycam_cinematic_workstation，这个是使用sitch 设计工具根据 [storycam-ui-design.md](docs/design/storycam-ui-design.md) 做的设计稿，现在可以使用 gstack 的 [$gstack-autoplan](/Users/vc3vc3/gstack/.agents/skills/gstack-autoplan/SKILL.md) 开始 plan，前面的产品设计文档在 docs 里”

教师批注：这个 prompt 很重要，因为它同时给了“设计稿来源”“计划技能”“文档上下文”三个入口。好的项目协作 prompt 不只是说“帮我计划”，而是告诉 AI 哪些材料是可信输入。

Prompt 2：补充项目规则

“StoryCam is an AI private story-theater product for ordinary users. It is not an industrial short-drama production backend.”

“Preserve the core loop: input story idea -> generate script, character assets, and scene assets -> user confirms -> generate storyboard script and 1-3 core storyboard images -> expand selected storyboard images -> generate one Seedance 2.0 clip per confirmed core storyboard group -> confirm clips -> system suggests stitching -> final video.”

教师批注：这是产品边界 prompt。它防止计划被设计稿带偏，也防止 AI 过早把 StoryCam 做成专业生产后台。读者可以学习：把“不是什么”写清楚，常常和“是什么”一样重要。

Prompt 3：批准 CEO 方向调整

“批准”

教师批注：这是一句很短但很关键的决策反馈。前面 CEO review 已经提出把第一版从完整工作站收窄到 Private Memory Trailer Spike，用户批准后，后续设计、工程和 DX 审查都围绕这个新范围展开。

Prompt 4：要求中文文档

“这些 plan 文档需要中文版本”

“英文的不用保留，中英文留一份即可”

教师批注：这是文档维护策略的修正。对长期项目来说，多语言双份文档会带来同步成本。用户选择中文单份，实际是在降低后续维护复杂度。

Prompt 5：追问下一步

“看下 gstack 技能包，下面改进行哪一步了？”

教师批注：这个 prompt 把“计划完成”推进到“流程选择”。它要求 AI 不只总结自己做了什么，还要检查工具链约定，判断下一步到底是实现、提交，还是继续审查。

Prompt 6：生成项目开发叙事章节

“你是一个‘项目开发叙事整理器’。我要把我和 Codex 在某个项目中的不同 session 整理成按时间顺序排列的 HTML 章节，最终串成一份完整的项目开发过程讲解文档。”

“页面不是普通聊天记录，而是一章可阅读、可学习、可串联进总文档的项目叙事。”

教师批注：这是元叙事 prompt。它把一次开发协作转换成可教学、可复盘的章节，强调“学习方法”而不只是“记录发生了什么”。

时间线

01 / 计划启动

用户原话 “这个是使用 sitch 设计工具根据 storycam-ui-design.md 做的设计稿，现在可以使用 gstack 的 $gstack-autoplan 开始 plan。”

Codex 总结读取 gstack-autoplan 技能说明和项目 docs，将 Stitch 设计稿、产品愿景、UI brief、山隐导演大师参考一起作为计划输入。

结果 / 影响：本轮不是自由头脑风暴，而是围绕已有项目材料进行结构化审查。

02 / 约束确认

用户原话 “Do not design the first version as a mobile-only app.” “Do not skip the script and asset confirmation stage.” “Seedance 2.0 calls in the MVP equal the number of confirmed core storyboard groups.”

Codex 总结将 AGENTS.md 视作项目事实源：Web-first、普通用户、确认故事世界、1-3 核心分镜组、每组最多一次真实视频调用。

结果 / 影响：这些约束成为后续所有取舍的裁判标准。

03 / CEO 审查

用户原话 “批准”

Codex 总结 CEO review 认为六工作台会拖慢 first magic，建议把 MVP 收窄成 Private Memory Trailer Spike：一个情绪模板、一个核心时刻、一个真实 Seedance clip。

结果 / 影响：产品方向发生关键变化：从“流程完整”转向“尽快证明私人故事视频的魔法”。

04 / 设计审查

Codex 总结 Design review 把 Phase 1 改为五步：输入私人时刻、确认故事世界、确认核心时刻、发送到视频生成、首个 clip 揭晓。Stitch 只保留结构，视觉和文案要转向私人小剧场。

结果 / 影响：设计不再照搬工作站，而是服务一个普通用户可理解的情绪路径。

05 / 工程审查

Codex 总结 Engineering review 发现真实视频生成不能同步请求完成，必须加入 GenerationJob、幂等键、artifact version、重试上限、取消、超时和删除 tombstone。

结果 / 影响：计划从产品流程升级为可落地的异步生成系统方案。

06 / DX 审查

Codex 总结 DX review 把本地开发契约提前到 Phase 0：先写 local-dev、testing、providers、jobs-and-errors、privacy-logging、api-contract 和 .env.example。

结果 / 影响：实现前先确保无密钥 mock flow 可跑、可调试、可测试。

07 / 中文收敛

用户原话 “这些 plan 文档需要中文版本。” “英文的不用保留，中英文留一份即可。”

Codex 总结将实施计划和测试计划收敛成中文单份文档，并更新 README 工程索引，避免中英文双份漂移。

结果 / 影响：项目计划文档更适合后续中文团队协作和复盘。

08 / 下一步判断

用户原话 “看下 gstack 技能包，下面改进行哪一步了？”

Codex 总结检查 gstack 技能包后判断：若继续开发，先进入 Phase 0；若只是把计划变更落 PR，则可用 /gstack-ship。

结果 / 影响：计划完成后的下一步被拆清楚，避免把“提交文档”和“开始实现”混为一谈。

关键时刻

转折点：从六工作台到一个真实 clip

问题：完整工作台看起来完整，但用户可能在看到真实结果前就流失。

为什么重要：StoryCam 的核心价值是私人情绪被拍成视频，不是流程本身。

最终处理：Phase 1 收窄为一个模板、一个核心时刻、一个真实 Seedance clip。

关键发现：Stitch 是参考，不是产品真相

问题：Stitch 设计有工作站气质，容易和普通用户的私人故事场景冲突。

为什么重要：视觉语气会影响用户是否愿意输入私密内容。

最终处理：保留布局骨架，替换专业话术和高压 cyber 气质。

架构决策：视频生成 job 化

问题：真实 provider 有延迟、成本、失败、重复提交和取消困难。

为什么重要：没有 job 模型就无法可靠处理刷新、重试、删除和晚到结果。

最终处理：计划加入 GenerationJob、幂等、版本追踪和 tombstone。

安全判断：隐私要进入 UI 和日志

问题：用户的私人故事可能被意外写入日志、debug 视图或 provider metadata。

为什么重要：信任是 StoryCam 的转化前提。

最终处理：加入 provider-send 确认、删除语义、24 小时 hosted retention 和脱敏日志 schema。

关键决策表

方案	当时看起来的好处	为什么放弃或保留	最终选择
完整六工作台 MVP	能完整展示 StoryCam 的分镜、资产、扩展和拼接概念。	太晚出现真实视频，容易验证的是 mock 工作流，不是用户价值。	放弃作为 Phase 1；转为后续 progressive depth。
Private Memory Trailer Spike	最快验证用户是否觉得真实 clip “像我的故事”。	范围更窄，但更贴近产品成败核心。	保留，成为 Phase 1 主线。
直接照搬 Stitch 视觉	能快速得到高完成度页面。	工作站气质和普通用户私人表达冲突。	放弃照搬；只保留结构和流程参考。
视频同步 API 调用	接口简单，Demo 容易写。	无法承受真实 provider 的等待、失败、取消和重复提交问题。	放弃；改为异步 `GenerationJob`。
中英文两份计划文档	英文保留原始审查细节，中文方便阅读。	双份文档会漂移，维护成本高。	保留中文单份 canonical docs。
计划完成后立即 ship	可以把文档变更快速落库。	如果目标是继续产品实现，ship 不是开发下一步。	区分路径：提交文档走 ship；继续实现走 Phase 0。

可复用方法

方法 1：产品单位对齐检查法

当 AI 产品涉及多个中间产物时，先问“用户真正购买的单位是什么”。本 session 里，真正单位不是工作台、分镜卡或 prompt packet，而是“我的私人故事被拍成一个可信片段”。这帮助团队把 Phase 1 收窄到一个真实 clip。

方法 2：设计稿降权法

对 AI 生成的设计稿，不要问“怎么完整实现它”，先问“哪些是结构证据，哪些只是风格噪声”。StoryCam 保留了 Stitch 的流程结构，放弃了不适合私人表达的 cyber workstation 气质。

方法 3：真实 provider 后果清单

只要从 mock 进入真实 provider，就要检查成本、延迟、幂等、重试、取消、删除、日志、额度和 policy refusal。这个清单能防止 Demo 架构在真实调用时崩掉。

方法 4：Phase 0 开发者契约

在写复杂功能前，先定义本地如何跑、mock 如何切、测试怎么跑、错误如何看、日志如何脱敏。这不是慢，而是在降低后续每一次调试的摩擦。

方法 5：文档单源化

如果团队主要用中文工作，就把 canonical plan 收敛成中文单份。多语言 companion 可以临时存在，但最终要避免两个版本互相漂移。

方法 6：计划后分叉判断

计划完成后不要自动进入“提交”或“开发”。先判断目标：如果要保存当前成果，走 ship；如果要继续实现，走计划里的下一阶段。这个区分能减少流程误用。

工程证据

Branch

main

未确认 / 未产生可记录 PR。

Commit

本 session 未产生可确认的新 commit。曾读取当前 HEAD 短 hash 供 gstack 日志使用，但不把它记录为本 session 产物。

Checks

代码测试未运行。原因：本 session 是计划和文档整理，不是功能实现或发布验证。

Deploy

未运行部署。

Files

docs/README.md
docs/engineering/storycam-web-mvp-implementation-plan.md
docs/engineering/test-plan.md
session-chapters/2026-04-25-storycam-autoplan-plan-docs.html

Commands / 操作

rg / sed / find：定位计划文档和 gstack 技能说明
git status --short：确认工作区变更
apply_patch：创建和更新文档
gstack-review-log：记录 plan review 完成状态

敏感信息处理

未记录 API key、token、cookie、完整 DSN、签名 URL、provider 原始 payload。涉及 secret 的配置统一写作 server-only 或 [REDACTED] 级别说明。

后续事项

已完成

完成 gstack-autoplan 的 CEO、Design、Eng、DX 审查。
确定 Phase 1 使用 Private Memory Trailer Spike。
将计划和测试计划收敛为中文单份文档。
更新 README 工程索引。
生成本 session 的项目叙事 HTML 章节。

待确认

是否先用 /gstack-ship 把计划文档单独提交。
是否把设计稿目录和 session 章节纳入版本控制，或继续保持未追踪。
Seedance 2.0 的真实接入方式、预算、额度和 secret 管理策略。
当前后续 session 中已有 app scaffold 和更多实现痕迹，本章不回填未在本 session 中确认的结果。

后续开发

进入 Phase 0：补齐 local-dev.md、testing.md、providers.md、jobs-and-errors.md、privacy-logging.md、api-contract.md。
维护 .env.example，默认 mock mode，不依赖真实 provider credentials。
随后进入 Phase 1，实现 暗恋雨夜 的一条 mock-to-real guided path。
在真实视频接入前完成 job、幂等、删除、日志脱敏和测试命令。